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(54) Method and system for securely controlling access to system resources in a distributed 
system 

(57) Embodiments of the present invention provide 
an improve method and system for securely controlling 

access to resources in a distributed computer system. .__ 100 

One embodiment of the present invention stores and 
binds a group identification to a target object and then 
uses membership checking to determine whether a cli- 
ent object which requests access to the target object is 
a member of a group with access rights to the target 
object. In this way, the present invention avoids perform- 
ing costly cryptographic operations in order to verify ac- 
cess rights of requesting objects, as was common in 
some prior art systems. 

A second embodiment of the present invention 
stores and binds a group identification to a target object 
reference and then passes the target object reference 
to client objects in the system. Since the target object 
reference includes a group identification entry, a first cli- 
ent object is able to determine which other clients in the 
system are members of the identified group. This deter- 
mination allows the first client object to pass the target 
object reference to the other members of the group with- 
out first communicating with the server for the target ob- 
ject. In this way, the present invention avoids the costly 
transaction costs of communicating with the server for 
the target object. 
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(54) Method and system for securely controlling access to system resources in a distributed 
system 



(57) Embodiments of the present invention provide 
an improve method and system for securely controlling 
access to resources in a distributed computer system. 
One embodiment of the present invention stores and 
binds a group identification to a target object and then 
uses membership checking to determine whether a cli- 
ent object which requests access to the target object is 
a member of a group with access rights to the target 
object. In this way, the present invention avoids perform- 
ing costly cryptographic operations in order to verify ac- 
cess rights of requesting objects, as was common in 
some prior art systems. 



A second embodiment of the present invention 
stores and binds a group identification to a target object 
reference and then passes the target object reference 
to client objects in the system. Since the target object 
reference includes a group identification entry, a first cli- 
ent object is able to determine which other clients in the 
system are members of the identified group. This deter- 
mination allows the first client object to pass the target 
object reference to the other members of the group with- 
out first communicating with the server for the target ob- 
ject. In this way, the present invention avoids the costly 
transaction costs of communicating with the server for 
the target object. 
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Description 

The method and system of the present invention re- 
lates generally to providing security in computer sys- 
tems and, more particularly, to controlling access to sys- 
tem resources by utilizing a group identity bound to an 
object reference or capability. 

In an object oriented system, an object is a compo- 
nent comprising data and operations which can be in- 
voked to manipulate the data. The operations (also 
called "methods") are invoked on the object by sending 
calls to the object. Each object has an object type that 
defines the operations that can be performed on objects 
of that type. One object type may inherit the object op- 
erations defined and implemented for other object 
types. For further description of object oriented design 
and programming techniques see "Object-Oriented 
Software Construction" by Bertrand Meyer, Prentice- 
Hall 1988, which is incorporated herein by reference. 

In client-server computing, typically there is a set of 
computers that can communicate with one another 
through a network connecting the computers. Some of 
these computers act as providers of services or func- 
tionality to other computers. The provider of a service 
or functionality is known as a "server", and the consumer 
of the service or functionality is called a "client". The cli- 
ent-server model also generalizes to the case where 
distinct programs or processes are running on the same 
computer and communicating with one another through 
some protected mechanism and are acting as providers 
and consumers of functionality. 

In object oriented distributed systems based upon 
the client-server model, there exist servers that provide 
object oriented interfaces to their clients. These servers 
support objects consisting of data and the associated 
software for manipulating the data according to the op- 
erations permitted by this type of object. Clients may ob- 
tain access to these objects and may execute calls on 
them by transmitting the calls to the server. At the server 
these calls are executed via the software associated 
with the object. The results of these calls are then trans- 
mitted back to the client. 

Currently, a number of companies have agreed to 
standardize certain object definitions and interfaces to 
permit the sharing of such objects with one another. One 
system, designed to enable participation in such inter- 
company sharing of objects, is called Distributed Ob- 
jects Environment ("DOE"), created by Sun Microsys- 
tems, Inc. 1 

DOE is an object-oriented system, providing remote 
access from clients to DOE objects. Server applications 
implement DOE objects. For any given DOE object, a 
DOE server can create an object reference that acts as 
a pointer to the DOE object. A DOE object reference can 
be passed around between different processes on one i 

1 .Sun. DOE. and Sun Microsystems. Inc. are trademarks or registered 
trademarks of Sun Microsystems. Inc., in the United States and other 
countries. 



machine or between different machines and it will still 
point to the original object 

When a client application at one location obtains a 
DOE object reference, it can send calls (method invo- 
s cation requests) to the target DOE object. The target 
DOE object can then execute these calls, possibly up- 
dating its internal state (its data) and possibly returning 
some results to its caller. As part of processing a method 
invocation, a server can itself invoke other objects, ere- 
io ating a chain of object invocations. 

The advent of such object sharing with entities 
which are outside of a user's direct control raises a 
number of security issues. For example, it is desired to 
allow DOE users to access objects that are scattered 
15 across large sets of machines. But it is essential to make 
sure that only authorized users are allowed to access 
objects, so the data the objects encapsulate is not avail- 
able to or changeable by unauthorized users. 

As a partial solution to such security concerns, 
7 -0 some servers provide secure access to their objects, so 
that only appropriately designated users can access the 
objects. When a client application wants to access to a 
secure object, it must establish an authenticated con- 
nection^ the server which contains the implementation 
?5 of the secure object. While establishing this connection, 
the client application must prove to the server which us- 
er the client application is representing. Thus for exam- 
ple, the client application may be representing the hu- 
man user Susan. (As part of the business of logging into 
'0 the client computer the human user purporting to be Su- 
san will probably have had to provide some kind of au- 
thenticating information, e.g., a password to the client 
computer.) After the authenticated connection has been 
established, the server will be convinced that the given 
5 connection is to an application which has been empow- 
ered to represent a given user. The server will record 
the name of this user and will associate this user's name 
with the given connection. The art of establishing au- 
thenticated connections is well understood. See for ex- 
* ample "Authentication in Distributed Systems: Theory 
and Practice" by Butler Lampson, Martin Abadi, Michael 
Burrows and Edward Wobber, ACM Transactions on 
Computer Systems, 10(4), November 1992. 

The normal DOE model is that clients invoke oper- 
> ations on remote objects. The server can require that 
the request be issued on an authenticated connection 
and can therefore validate that the client application is 
representing an authenticated user. The server can then 
perform a check to see that this authenticated user is 
' really authorized to do the operation. 

Complications arise as soon as the user wants a 
server to perform some action that requires the server 
to access some other secure server. For example, a us- 
er may request a client application to obtain a compound 
document (e.g., an annual sales report containing 
spreadsheet graphs and explanatory text), part of which 
is located on a first server (e.g., the text) and part on a 
second server (e.g., the graphs). The first server can 
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authenticate the requesting user and verify that the user 
is authorized to make the request. However if the first 
server then must access the second server for some da- 
ta to complete the users response, the second server 
must authenticate the first server and must ensure that 
the first server was granted access by the client or has 
adequate access permissions to perform its requested 
action on the object. This problem is referred to as the 
delegation problem. It occurs whenever it is necessary 
for a client to delegate part of its authority to a server in 
order to allow it to get its job done. 

Delegation by the user to a given server to act in 
the user's name in accessing a second server requires 
that users trust many machines, which leaves them 
open to security attacks or the users must trust only a 
small set of known machines, which severely limits the 
user's access to desirable objects. Similarly, accepting 
access requests from clients distributed throughout the 
network poses substantial security risks to the servers 
themselves. Thus, it would be desirable to develop an 
improved method and system for securely delegating 
access control rights in a distributed, networked envi- 
ronment. 

The present invention is an elegant and simple way 
to solve the problem of securely dealing with access re- 
quests from various servers in a distributed computer 
system within a networked environment, and is more ful- 
ly described below. 

Embodiments of the present invention provide an 
improved method and system for securely controlling 
access to resources in a distributed computer system. 
One embodiment of the present invention stores and 
binds a group identification with a target object and then 
uses membership checking to determine whether a cli- 
ent object which requests access to the target object op- 
erates on behalf of a user who is a member of this group. 
In this way, the present invention avoids performing 
costly cryptographic operations in order to verify access 
rights of requesting objects, as was common in some 
prior art systems. 

A second embodiment of the present invention 
stores and binds a group identification to a target object 
reference and then passes the target object reference 
to client objects in the system. Since the target object 
reference includes a group identification entry, a first cli- 
ent object is able to determine which other clients in the 
system are members of the identified group. This deter- 
mination allows the first client object to pass the target 
object reference to the other members of the group with- 
out first commun icating with the server for the target ob- 
ject. In this way, the present invention avoids the costly 
transaction costs of communicating with the server for 
the target object. 

The detailed descriptions which follow are present- 
ed largely in terms of methods and symbolic represen- 
tations of operations on data bits within a computer. 
These method descriptions and representations are the 
means used by those skilled in the data processing arts 



most effectively to convey the substance of their work 
to others skilled in the art. 

A method is here, and generally, conceived to be a 
self-consistent sequence of steps leading to a desired 
s result. These steps require physical manipulations of 
physical quantities. Usually, though not necessarily, 
these quantities take the form of electrical or magnetic 
signals capable of being stored, transferred, combined, 
compared, and otherwise manipulated. It proves con- 
10 venient at times, principally for reasons of common us- 
age, to refer to these signals as bits, values, elements, 
symbols, characters, terms, numbers, or the like. It 
should be borne in mind, however, that all of these and 
similar terms are to be associated With the appropriate 
is physical quantities and are merely convenient labels ap- 
plied to these quantities. 

Useful machines for performing the operations of 
the present invention include general purpose digital 
computers or similar devices. The general purpose 
20 computer may be selectively activated or reconfigured 
by a computer program stored in the computer. A special 
purpose computer may also be used to perform the op- 
erations of the present invention. In short, use of the 
methods described and suggested herein is not limited 
25 to a particular computer configuration. 

Figure 1 is a block diagram of a computer system 
for practicing the preferred embodiment of the 
present invention; 
30 Figure 2 is a flow diagram illustrating the preferred 
steps of the first embodiment for securely control- 
ling access to system resources; and 
Figure 3 is a flow diagram illustrating the preferred 
steps of a second embodiment for securely control- 
35 ling access to system resources. 

Embodiments of the present invention provide an 
improved method and system for securely controlling 
access to resources in a distributed computer system. 

40 One embodiment of the present invention stores and 
binds a group identification with a target object and then 
uses membership checking to determine whether a cli- 
ent object which requests access to the target object op- 
erates on behalf of a user who is a member of this group. 

45 in this way, the present invention avoids performing 
costly cryptographic operations in order to verify access 
rights of requesting objects, as was common in some 
prior art systems. 

A second embodiment of the present invention 

so stores and binds a group identification to a target object 
reference and then passes the target object reference 
to client objects in the system. Since the target object 
reference includes a group identification entry, a first cli- 
ent object is able to determine which other clients in the 

55 system are members of the identified group. This deter- 
mination allows the first client object to pass the target 
object reference to the other members of the group with- 
out first communicating with the server for the target ob- 
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ject. In this way, the present invention avoids the costly 
transaction costs of communicating with the server for 
the target object. 

Figure 1 is a block diagram of a computer system 
100 for practicing the preferred embodiment of the 
present invention. The computer system 100 includes a 
computer 101, an input device 103, a storage device 
105, and a display device 107. The display device 107 
displays a graphical user interface (GUI) 109. The GUI 
presents information through icons, and a user invokes 
commands by pointing to or manipulating the icons. The 
computer 1 0 1 includes a processor 1 1 1 , a memory 1 1 3, 
and an interface 115 for enabling communication be- 
tween the processor 111 and peripheral devices such 
as the input device 103 and the display device 107. 

The computer memory contains a number of items 
including a client object 117, a compound document 
server object 1 1 9, and a spreadsheet server object 121. 
The contents of the memory 113 will be discussed in 
more detail below. 

The various embodiments of the present invention 
are perhaps best described by way of example. Both 
embodiments described herein will be discussed in the 
context of creating and printing a compound document. 
A compound document typically includes both text and 
graphics. For example, an annual sales report which 
contains charts and graphs depicting yearly sales 
growth and explanatory text would be implemented as 
a compound document. Oftentimes, the charts and 
graphs are stored under control of a spreadsheet server 
while the text for the compound document is stored un- 
der control of a compound documen: server, along with 
a link to the charts and graphs. While the present exam- 
ples take place between different processes residing on 
one computer, those of ordinary skill in the art will un- 
derstand that the teachings herein are equally applica- 
ble to objects and processes distributed throughout a 
networked environment. 

Before processing begins in either embodiment, 
however, certain preconditions should exist within the 
computer system 1 00. It is assumed that a user (or "prin- 
cipal") has successfully logged on to and has acquired 
credentials for the system 100 and has invoked the cli- 
ent object 117. In the present example, the client object 
117 typically corresponds to a process containing a 
wordprocessing application. Principal credentials are 
then stored with the client object 117 in order to indicate 
that the object 117 is acting on behalf of the principal. 
Furthermore, the principal is associated with a group of 
other principals having access privileges on the compu- 
ter system 1 00. For example, a salesperson may be as- 
sociated with a group for the Sales Department. Each 
group defined in the system 100 has a unique group 
identifier associated with it. In addition, a mechanism (e. 
g., mechanism 123) for checking membership creden- 
tials should be present to determine whether an object 
acting on behalf of a principal is or is not a member of 
a specified group. Any well known method or system for 
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implementing a membership mechanism may be used 
to implement this aspect of the system 100. 

Figure 2 is a flow diagram illustrating the preferred 
steps of the first embodiment for securely controlling ac- 
cess to system resources. The steps of Figure 2 are typ- 
ically initiated in response to user input. Suppose that 
the principal initiates a request on the client 11 7 to create 
a spreadsheet (Step 201 ). In response to the input, the 
client object 117 sends a Create request to the spread- 
sheet server object (Step 203). The request indicates 
that a spreadsheet object should be instantiated. Tne 
request also includes the group identifier associated 
with the user on whose behalf the compound document 
server operates. 

The spreadsheet server object receives the request 
and creates the spreadsheet object (Step 205). The 
spreadsheet server object then stores with the spread- 
sheet object the group identifier, along with art indication 
of the access rights the group members have with re- 
spect to the spreadsheet object (Step 207). Finally, the 
spreadsheet server object generates an unforgeable 
number and stores the unforgeable number with the 
spreadsheet object (Step 209). In this way, the spread- 
sheet server object, when presented with the unforgea- 
ble number by a client object requesting access to the 
server object, can have some assurance that the re- 
questing client has the authority to access the spread- 
sheet object. The unforgeable number is often called a 
"capability". An unforgeable number is one that is com- 
putationally difficult to determine. 

The spreadsheet server object then sends to the cli- 
ent object 117, a spreadsheet object reference (Step 
21 1 ). In the preferred embodiment, the spreadsheet ob- 
ject reference comprises the previously generated un- 
forgeable number. 

Once the spreadsheet server object returns 
processing control to the client object, the client object 
finds a compound document server that operates on be- 
half of a principal in the group (Step 21 3). Next the client 
object sends a request to create a compound document 
to the compound document server 119 (Step 215). The 
Create request includes an indication that a compound 
document should be created. The Create request also 
includes the spreadsheet object reference so that the 
compound document server knows which spreadsheet 
object to incorporate into its compound document. Fi- 
nally, the Create request includes a selected group iden- 
tifier so that the compound document server can later 
determine whether a principal requesting access to the 
compound document is authorized to access the com- 
pound document. 

The compound document server creates the com- 
pound document and stores the spreadsheet object ref- 
erence and the group identifier in the compound docu- 
ment (Step 217). Next, the compound document server 
generates an unforgeable number and stores the un- 
forgeable number with the compound document object. 
In this way, the compound document server object, 
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when presented with the unforgeable number by a client 
object requesting access to the compound document 
object, can have some assurance that the requesting 
client has the authority to access the compound docu- 
ment object. 

The compound document server object 119 then 
sends to the client object 117, a compound document 
object reference (Step 219). In the preferred embodi- 
ment, the compound document object reference com- 
prises the unforgeable number generated by the com- 
pound document server object. 

At some later point in time the client object sends a 
print request to the compound document server (Step 
221). The Print request passes the compound docu- 
ment reference and the identity of the client's principal 
to the compound document server. The client uses any 
well known authentication mechanism to prove to the 
compound document server that it has the right to op- 
erate on behalf of the client's principal. By passing the 
compound document reference and the identity of the 
client's principal to the compound document server, the 
compound document server is able to determine which 
compound document to print and can verify that the cli- 
ent object 117 has permission to print the compound 
document by checking that the authenticated identity 
belongs to the group specified when the compound doc- 
ument was created, and by comparing the unforgeable 
number in the object reference with the unforgeable 
number in the object. 

In order to print the compound document, the com- 
pound document server needs to have the data associ- 
ated with the spreadsheet object. So, the compound 
document server sends a Get Data request to the 
spreadsheet server (Step 223). The Get Data request 
includes the spreadsheet object reference so that the 
spreadsheet server knows which spreadsheet object 
from which to retrieve the data. The Get Data request 
also includes the identity of the principal on whose be- 
half the compound document server operates. 
K The compound document server will authenticate 
itself to the spreadsheet server (Step 225). Any well 
'known technique for authenticating principals can be 
used to implement this aspect of applicant's embodi- 
ment. If the compound document server is successfully 
authenticated then the spreadsheet server attempts to 
determine whether the compound document server has 
access rights which permit it to retrieve data from the 
spreadsheet object. To determine access rights the 
spreadsheet server retrieves the group identifier from 
the spreadsheet object. The spreadsheet server then 
sends the group identifier and the authenticated princi- 
pal identifier to the membership mechanism 123, along 
with a request to determine whether the authenticated 
principal is a member of the group with access rights to 
the spreadsheet object (Step 227). Any well known 
mechanism for checking group membership may be 
used to implement this aspect of applicant's embodi- 
ment. 



If the compound document server's authenticated 
principal is a member of the specified group then the 
spreadsheet server makes yet another check to ensure 
that the compound document is authorized to access 
s the spreadsheet object. The spreadsheet server re- 
trieves the unforgeable number from the spreadsheet 
server reference and compares it to the unforgeable 
number stored with the spreadsheet server object (in a 
preferred embodiment this step would preferably be im- 
10 plemented first) (Step 229). If the unforgeable numbers 
match then the spreadsheet server permits the com- 
pound document server to retrieve the necessary data 
from the spreadsheet object, subject to the access rights 
stored with the object (Step 231 ). 

Once the spreadsheet data is retrieved, the com- 
pound document server sends the compound document 
data to a print server for printing (Step 233). 

One of the benefits associated with the first embod- 
iment is that no cryptographic operations are needed to 
determine whether a client who is requesting access to 
an object is authorized to access the object. Instead, the 
first embodiment accomplishes this authorization check 
by maintaining a group identifier in the state data of the 
spreadsheet object and then using the group identifier 
to determine whether the requesting client operates on 
behalf of a user who is a member of the appropriate 
group. This group membership check is typically less 
expensive to perform than a cryptographic operation. 

Another advantage of the first embodiment is that 
the spreadsheet server can determine who has access 
to a given object just using state data maintained at the 
spreadsheet object. In other prior art implementations 
this was not possible because only object references 
stored access rights information Access rights informa- 
tion was not stored with the object itself. 

Figure 3 is a flow diagram illustrating the preferred 
steps of a second embodiment for securely controlling 
access to system resources The steps of Figure 3 are 
typically initiated in response to user input. Suppose that 
the principal initiates a roquos! on the client 1 1 7 to create 
a spreadsheet (Step 301 ) in response to the input, the 
client object 117 sends a Create request to the spread- 
sheet server object (Stop 303) The request indicates 
that a spreadsheet object should be instantiated. The 
request also includes the group identifier associated 
with the principal on whose bona!! the compound docu- 
ment server operates. 

The spreadsheet server object receives the request 
and creates the spreadsheet object (Step 305). The 
spreadsheet server object then sends to the client object 
117, a spreadsheet object reference (Step 307). In the 
second embodiment, the spreadsheet object reference 
comprises the group identifier sent with the Create re- 
quest, an entry indicating the access rights privileges of 
the group, and a spreadsheet object identifier. The 
spreadsheet object reference may be run through a 
cryptographic one-way hash function to produce a cryp- 
tographic checksum on the object reference data. The 
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cryptographic checksum is also saved in or associated 
with the spreadsheet object reference. The spreadsheet 
object reference then has greater protection against for- 
gery. 

Once the spreadsheet object server returns 
processing control to the client object, the client object 
sends a request to create a compound document to the 
compound document server 1 1 9 (Step 309). The Create 
request includes an indication that a compound docu- 
ment should be created. Tne Create request also in- 
cludes the spreadsheet object reference so that the 
compound document server knows which spreadsheet 
object to incorporate into its compound document. Fi- 
nally, the Create request includes a selected group iden- 
tifier so that the compound document server can deter- 
mine- whether an object operating on behalf of some 
principal requesting access to the compound document 
is authorized to access the compound document. 

The compound document server creates the com- 
pound document and stores the spreadsheet object ref- 
erence in the compound document (Step 311). The com- 
pound document server object 119 then sends to the 
client object 117, a compound document object refer- 
ence (Step 313). In the second embodiment, the com- 
pound document object reference comprises the group 
identifier, an entry which indicates the access rights of 
those in the group, an identifier for the compound doc- 
ument, and a cryptographic checksum generated by the 
compound document server during creation of the com- 
pound document reference. 

At some later point in time the client object sends a 
print request to the compound document server (Step 
315). The Print request passes the compound docu- 
ment reference and the identity of the client's principal 
to the compound document server. The client uses any 
well known authentication mechanism to prove to the 
compound server that it has the right to operate on be- 
half of the client's principal (Step 317). In this way the 
compound document server understands which com- 
pound document to print and can verify that the client 
object 117 has permission to print the compound docu- 
ment by using a cryptographic checksum as described 
in more detail below 

In order to print the compound document, the com- 
pound document server needs to have the data associ- 
ated with the spreadsheet object. So, the compound 
document server sends a Get Data request to the 
spreadsheet server (Step 319). The Get Data request 
includes the spreadsheet object reference so that the 
spreadsheet server knows the spreadsheet object from 
which to retrieve the data. The Get Data request also 
includes the identity of the principal on whose behalf the 
compound document server operates. 

The spreadsheet server authenticates the com- 
pound document server (Step 321). Any well known 
technique for authenticating principals can be used to 
implement this aspect of applicant's second embodi- 
ment. If the compound document server is successfully 



authenticated then the spreadsheet server attempts to 
determine whether the compound document server has 
access rights which permit it to retrieve data from the 
spreadsheet object (Step 323). To determine access 
5 rights the spreadsheet server retrieves the group iden- 
tifier associated with the spreadsheet object reference. 
The spreadsheet server then retrieves the spreadsheet 
identifier from the spreadsheet object reference. Finally, 
the spreadsheet server sends the retrieved information 
10 to the membership mechanism 123, along with a re- 
quest to determine whether the authenticated principal 
is a member of the identified group with access rights to 
the spreadsheet object. Any well known mechanism for 
checking group membership may be used to implement 
™ this aspect of applicant's second embodiment. 

If the authenticated principal is a member of the 
identified group then the spreadsheet server makes Yet 
another check to ensure that the compound document 
is authorized to access the spreadsheet object. The 
20 spreadsheet server retrieves the cryptographic check- 
sum from the spreadsheet object reference and then 
recomputes the cryptographic checksum for the spread- 
sheet object (Step 325). Next, the spreadsheet server 
compares the retrieved checksum with the recomputed 
2S checksum (Step 327). If the checksums match then the 
spreadsheet server permits the compound document 
server to retrieve the necessary data from the spread- 
sheet object subject to the access rights in the object 
reference. 

30 Once the spreadsheet data is retrieved, the com- 
pound document server sends the compound document 
data to a print server for printing (Step 329). 

One of the benefits of the second embodiment is 
that the client object, by maintaining state about which 
3S group is authorized to use an object reference and what 
other members are in the group, can pass that object 
reference associated with that group to another principal 
in the group without having to engage in any message 
exchanges with the server. Avoiding such interactions 
40 with the spreadsheet server improves performance and 
efficiency. 

While specific embodiments have been described 
herein for purposes of illustration, various modifications 
may be made without departing from the spirit and 
45 scope of the invention. Accordingly, the invention is not 
limited to the above described embodiments. 

For example, there are a number of ways the two 
embodiments might be modified according to tech- 
niques widely understood by someone familiar with the 
so current art. In the first embodiment, the group identifier 
might not only be stored in the object, but also sent with 
the object reference as a hint to the client. This hint could 
be used to bypass a message exchange with the server 
when the object reference is passed to a second client 
ss The first client could check that the second client is in 
the group. Without this hint, the first client must request 
the group identifier from the server, which involves a 
message exchange. 
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In the second embodiment, the server could cache 
object references with the object when they are present- 
ed for use. On a subsequent presentation, the server 
could check the object reference sent by the client with 
those in the cache. This means that if the object refer- 
ence was presented by a different client in the same 
group, the server need not recompute the cryptographic 
checksum, which would reduce the computation by the 
server for that access and hence increase its perform- 
ance. 



Claims 

1. A method executed in a computer system for con- 
trolling access to system resources in a distributed 
computer system, the method comprising the steps 
of: 

sending a request from a client object to a 
spreadsheet server to bind a group identifier to a 
spreadsheet object; 

under control of the spreadsheet server, 
obtaining a spreadsheet object; 
storing the group identifier with the 
spreadsheet object; 

generating a unforgeable checksum; 
storing the unforgeable checksum with 
the spreadsheet object; 

sending the unforgeable checksum to 
the client object; 

under control of the client object, 

sending a request to a compound doc- 
ument server to print a compound document; 

under control of the compound document 
server, 

sending a request to the spreadsheet 
server requesting that the spreadsheet server send 
back data from a spreadsheet object, the request 
including a group identifier and the unforgeable 
checksum; 

under control of the spreadsheet server, 

permitting or denying access to the 
spreadsheet object based on an analysis of the 
group identifier. 

2. A method executed in a computer system for facil- 
itating access control to system resources in a dis- 
tributed computer system, the distributed computer 
system including a client object, a first server object, 
a target object, and a second server object, each of 
the objects belonging to one or more specified 
groups of objects residing in the computer system, 
the method comprising the steps of: 

under control of the first server object, 

storing a group identifier with the target 
object, the group identifier identifying the group of 
objects in the system with access privileges to the 
target object; 



under control of a second server object, 
obtaining a container object; 
sending a request to the first server ob- 
ject requesting access to the target object, the re- 
s quest including a principal identifier which identifies 
a principal on whose behalf the second server ob- 
ject operates; and 

under control of the first server, 
verifying that the second server has permis- 
10 sion to access the target object by using the group 
identifier stored in the target object and the principal 
identifier contained in the request from the second 
server. 

is 3. The method of claim 2 wherein the step of obtaining 
the container object further comprises the steps of: 
under control of the first server object, 

sending a target object reference to the 
client object, the target object reference indicating 
20 the location of the target object in the computer sys- 
tem; 

under control of the client object, 

locating a second server which oper- 
ates on behalf of a member of the group to which 
25 the client object belongs; 

sending a request to the located second 
server requesting that the second server obtain a 
container object which references the target object, 
the request from the client object to the second 
30 server object including the target object reference, 
the request also including a group identifier which 
identifies the group to which the client object be- 
longs; 

under control of the second server, 
35 obtaining the container object; and 

storing the target object reference and 
the group identifier in the container object. 

4. The method of claim 2 wherein the step of sending 
^0 the request from the second server to the first server 
further comprises the steps of: 

under control of the client object, 

sending a request to the second server 
to use the container object, the request including 
45 the reference for the container object and an iden- 
tifier for the client object's principal; and 
under control of the second server, 

in response to the request from the cli- 
ent object, sending a request to the first server to 
50 access the target object, the request including the 
reference for the target object and the identifier for 
the principal on whose behalf the second server op- 
erates. 

55 5. The method of claim 4 further comprising the steps 
of: 

under control of the first server, 

authenticating the second server using 
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the identity of the principal sent from the second 
server to the first server. 

6. The method of claim 5 further comprising the steps 
<* " 5 

when the second server is authenticat- 
ed and determined to be a member of the group with 
access rights to the target object, determining 
whether the second server is authorized to access 
the target object in the requested way by w 

retrieving an unforgeable number from 
the reference for the first server; 

comparing the retrieved unforgeable 
number with an unforgeable number stored with the 
target object; and 1S 

when the unforgeable numbers match, per- 
mitting the second server to access the target ob- 
ject, subject to the access rights of the second serv- 
er. 

20 

7. The method of claim 2 wherein the step of verifying 
that the second server has permission to access the 
target object further comprises the steps of: 
under control of the first server, 

retrieving the group identifier from the 25 
target object; 

sending the retrieved group identifier 
and the principal identifier to a membership mech- 
anism, along with a request to determine whether 
the principal is a member of the group with access 30 
rights to the target object; and 

when the second server is determined to be 
operating on behalf of a principal who is a member 
of the group with access rights to the target object, 
permitting the second server to access the target 35 
object. 



8. 



The method of claim 2 further comprising the steps 
of: 

sending a request from the client object to the 40 
first server object, the request indicating that the 
first server object should create the target object; 
and 

under control of the first server object, 

creating the target object; and 45 
storing an indication of the access rights 

that group members have with respect to the target 

object. 

A computer system for facilitating access control to so 
system resources in a distributed computer system, 
the distributed computer system including a client 
object, a first server object, a target object, and a 
second server object, each of the objects belonging 
to one or more specified groups of objects residing ss 
in the computer system, the system comprising: 
the first server object configured to, 

store a group identifier with the target 



object, the group identifier identifying the group of 
objects in the system with access privileges to the 
target object; 

the second server object configured to, 
obtain a container object; 
send a request to the first server object 
requesting access to the target object, the request 
including a principal identifier which identifies a prin- 
cipal on whose behalf the second server object op- 
erates; and 

the first server configured to, 

verify that the second server has per- 
mission to access the target object by using the 
group identifier stored in the target object and the 
principal identifier contained in the request from the 
second server. 

10. The system of claim 9 wherein obtaining the con- 
tainer object further comprises a system wherein: 
the first server object is configured to, 

send a target object reference to the cli- 
ent object, the target object reference indicating the 
location of the target object in the computer system; 
the client object is configured to, 

locate a second server which operates 
on behalf of a member of the group to which the 
client object belongs: and 

send a request to the located second 
server requesting that the second server obtain a 
container object which references the target object, 
the request from the client object to the second 
server object including the target object reference, 
the request also including a group identifier which 
identifies the group to which the client object be- 
longs; and 

the second server is configured to, 
obtain the container object; and 
store the target object reference and the 
group identifier in the container object. 

11. The system of claim 9 wherein sending the request 
from the second server to the first server further 
comprises a system wnoroin 

the client object is configured to, 

send a requost to the second server to 
use the container object the request including the 
reference for the container object and an identifier 
for the client object's principal, and 

the second server is configured to, 

in response to the request from the cli- 
ent object, send a request to the first server to ac- 
cess the target object, the request including the ref- 
erence for the target object and the identifier for the 
principal on whose behalf the second server oper- 
ates. 

12. The system of claim 11 further comprising: 
the first server configured to, 
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authenticate the second server using 
the identity of the principal sent from the second 
server to the first server. 

13. The system of claim 12 further comprising mecha- 
nisms configured to: 

when the second server is authenticat- 
ed and determined to be a member of the group with 
access rights to the target object determine whether 
the second server is authorized to access the target 
object in the requested way by, 

retrieve an unforgeable number from 
the reference for the first server, 

compare the retrieved unforgeable 
number with an unforgeable number stored with the 
target object; and 

when the unforgeable numbers match, permit 
the second server to access the target object, sub- 
ject to the access rights of the second server. 

14. The system of claim 9 wherein verifying that the 
second server has permission to access the target 
object further comprises a system wherein: 

the first server is configured to, 

retrieve the group identifier from the tar- 
get object; 

send the retrieved group identifier and 
the principal identifier to a membership mechanism, 
along with a request to determine whether the prin- 
cipal is a member of the group with access rights to 
the target object; and 

when the second server is determined to op- 
erate on behalf of a principal who is a member of 
the group with access rights to the target object, 
permitting the second server to access the target 
object. 

15. The system of claim 9 further comprising mechani- 
sims configured to: 

send a request from the client object to the 
first server object, the request indicating that the 
first server object should create the target object; 
and 

wherein the first server object is configured to, 
create the target object; and 
store an indication of the access rights 

that group members have with respect to the target 

object. 

16. A computer program means for facilitating access 
control to system resources in a distributed compu- 
ter system, the distributed computer system includ- 
ing a client object, a first server object, a target ob- 
ject, and a second server object, each of the objects 
belonging to one or more specified groups of ob- 
jects residing in the computer system, the program 
comprising: 

code for the first server object configured to, 



store a group identifier with the target 
object, the group identifier identifying the group of 
objects in the system with access privileges to the 
target object; 

code for the second server object configured 

to, 

obtain a container object; 
send a request to the first server object 
requesting access to the target object, 
the request including a principal identifier which 
identifies a principal on whose behalf the second 
server object operates; and 

code for the first server configured to, 

verify that the second server has per- 
mission to access the target object by using the 
group identifier stored in the target object and the 
principal identifier contained in the request from the 
second server; 

wherein the codes are stored on a tangible 
medium. 

17. The program means of claim 16 wherein obtaining 
the container object further comprises: 

code for the first server object config- 
ured to, 

send a target object reference to the cli- 
ent object, the target object reference indicating the 
location of the target object in the computer system; 
code for the client object configured to, 

locate a second server which operates 
on behalf of a member of the group to which the 
client object belongs; and 

send a request to the located second 
server requesting that the second server obtain a 
container object which references the target object, 
the request from the client object to the second 
server object including the target object reference, 
the request also including a group identifier which 
identifies the group to which the client object be- 
longs; and 

code for the second server configured to, 

obtain the container object; and 

store the target object reference and the 
group identifier in the container object. 

18. The program means of claim 16 wherein sending 
the request from the second server to the first server 
further comprises: 

code for the client object configured to, 

send a request to the second server to 
use the container object, the request including the 
reference for the container object and an identifier 
for the client object's principal; and 

code for the second server configured to, 

in response to the request from the cli- 
ent object, send a request to the first server to ac- 
cess the target object, the request including the ref- 
erence for the target object and the identifier for the 
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principal on whose behalf the second server oper- 
ates. 



19. The program means of claim 1 8 further comprising: 

code for the first server configured to, s 
authenticate the second server using 
the identity of the principal sent from the second 
server to the first server. 



20. The program means of claim 1 9 further comprising 10 
code configured to: 

determine whether the second server is 
authorized to access the target object in the re- 
quested way, when the second server is authenti- 
cated and determined to be a member of the group is 
with access rights to the target object, by, 

retrieving an unforgeable number from 
the reference for the first server; 

comparing the retrieved unforgeable 
number with an unforgeable number stored with the 20 
target object; and 

when the unforgeable numbers match, per- 
mitting the second server to access the target ob- 
ject, subject to the access rights of the second serv- 
er. 25 



21. The program means of claim 16 wherein verifying 
that the second server has permission to access the 
target object further comprises: 

code for the first server configured to, 30 
retrieve the group identifier from the tar- 
get object; 

send the retrieved group identifier and 
the principal identifier to a membership mechanism, 
along with a request to determine whether the prin- 35 
cipal is a member of the group with access rights to 
the target object; and 

when the second server is determined to op- 
erate on behalf of a principal who is a member of 
the group with access rights to the target object, 40 
permitting the second server to access the target 
object. 

22. The program means of claim 16 further comprising 
code configured to: 45 

send a request from the client object to the 
first server object, the request indicating that the 
first server object should create the target object; 
and 

wherein the code for first server object is con- so 
figured to, 

create the target object; and 
store an indication of the access rights 
that group members have with respect to the target 
object. 55 
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